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DISCLAIMER 


The  contents  of  this  publication  do  not  necessarily  reflect  the  views  or 
policies  of  the  Bureau  of  Land  Management  and,  therefore,  should 
not  be  construed  as  official  Department  or  Agency  positions. 

Reproduction,  in  whole  or  in  part,  or  other  distribution  must  be 
authorized  by  Melanie  Rhinehart,  Systems  Implementation  Specialist, 
Branch  of  ALMRS  Implementation,  (303)  236-9940. 
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EDITOR'S  PREFACE 


This  handbook  is  designed  to  help  Bureau  personnel 
understand  and  interpret  Data  Flow  Diagrams,  those 
spaghetti-like  diagrams  that  some  consider 
intimidating.  It  is  our  hope  that  we  will  be  able  to 
unravel  most  of  the  mystery  as  well  as  prove  the 
benefits  associated  with  these  diagrams. 

If  you  can  answer  yes  to  even  one  of  the  following 
questions,  we  believe  the  contents  of  this  handbook 
will  be  of  immeasurable  value  to  you! 
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Is  automation  looming  in  your  future? 

Do  you  want  a  good  tool  that  will  help  you  get  a  handle 
on  what  you  will  need  for  an  automated  system? 

Do  you  want  your  specifications  to  be  as  accurate  and 
complete  as  they  can  be,  before  you  start  spending 
money? 

Do  you  need  a  clearer  understanding  of  the  tasks  and 
processes  normally  performed  in  your  office? 

Do  you  wish  you  could  identify  duplicate  or  overlapping 
tasks  that  are  costing  you  money  and  valuable 
employee  time? 

Do  you  often  think  there  must  be  a  better  way  to  do 
things,  but  you're  not  quite  sure  what  that  way  is? 


Do  you  get  the  feeling  we  may  be  able  to  help?  (If  so,  read  on!) 
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OVERVIEW 
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WHAT  IS  A  DATA  FLOW  DIAGRAM? 


As  used  in  the  Bureau  of  Land  Management,  a  data 
flow  diagram  (or  DFD,  in  government  nomenclature)  is 
a  picture  of  how  the  Bureau  processes  cases.  It  shows 
the  flow  of  data  through  various  steps  of  a  process. 

It  identifies  what  the  data  is- 

where  it  comes  from-- 

-and- 

where  it's  going. 

In  its  simplest  form,  a  DFD  looks  something  like  this: 


Stuff H         Process        ^ Processed 

Stuff 


Reprinted  by  permission  from 
Applied  Structured  Analysis  Workshop 
Logical  Conclusions,  Inc. 

pp.  8.2  copyright  1988 
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WHY  DFDS? 

Bureau  automation  will  affect  the  way  we  handle  data. 
It  is  not  intended  to  change  people,  places,  or  lines  of 
authority  and  control. 


SO  --  WHY  DFDS?? 

DFDs,  like  the  Bureau's  automation  plan,  focus  only  on 
data,  not  lines  of  authority  and  control,  UNLIKE  flow 
charts  which  incorporate  these  factors. 

DFDs  show  us  only  what  we  need  to  know  to  make 
wise  decisions  concerning  automation. 


ALSO-- 


Tasks  (processes)  are  multifaceted. 

Each  process  is  made  up  of  many  interrelated  and 
intertwined  steps,  all  of  which  are  needed  to  perform  a 
particular  process. 

When  you  think  of  the  various  steps  and  the 
connections,  you  readily  think  a  network  of  some  type. 

DFDs  merely  show  this  network. 


WHAT'S  INVOLVED? 

Data  Flow  Diagrams  are  one  of  3  tools  used  in  the 
Structured  Analysis  process. 

The  other  two  are: 
Input — ►Process — ►Output  Narrative 


-and- 


a  data  dictionary. 


© 


HUH? 


Structured  Analysis  is  a  systematic  approach  or 
technique  that  defines  a  major  process  by  identifying 
all  the  requirements  associated  with  that  process.  It 
divides  a  complex  process  into  smaller,  bite-size 
pieces. 


Data  Flow  Diagrams 

are 
PART 

of  the  Structured  Analysis  process. 

They  show  the  logical  elements  or  parts  of 

a  process  at  each  level  of  the  process. 


The  Input-Process-Output  narrative  describes  the 
lowest  (-or-  primitive)  level  of  a  process,  which  cannot 
be  subdivided  any  further.  The  narrative  is  a  step-by- 
step  account  of  what  takes  place  in  that  primitive 
process.  It  describes  the  logical  order  of  execution. 

Each  narrative  contains  the  following  information  (most 
of  which  you  would  expect): 

-  Primitive  process  name 

-  its  identifier  or  process  number 

-  main  (-or-  parent)  process  name  immediately  preceding  the  primitive 

level 

-  general  description 

-  applicable  policies  and  procedures 

-  constraints 

-  actual  input-process-output  narrative 
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The  Data  Dictionary  defines  the  terms  and 
abbreviations  or  symbols  used  in  the  diagram  and 
narrative. 

The  data  dictionary  defines  the  data  flows  in 
alphabetical  order,  according  to  data  name. 

Each  entry  of  the  dictionary  would  contain  the  following 
information: 

-  data  name 

-  initials  or  abbreviations  used  because  the  name  was  too  lengthy  to 

appear  on  the  diagram 

-  description  of  characteristics  and  uses 

-  data  type  (e.g.,  set;  record;  data  aggregate  which  represents  a  logical 

group  of  data  items;  and  element) 

-  security  considerations  for  both  retrieval  and  update 

-  definition  (used  primarily  for  composite  data) 
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IS  THAT  ALL  THERE  IS  TO  IT? 


Essentially...  Yes! 

Of  course,  when  a  DFD  identifies  all  the  levels 
associated  with  a  particular  process,  the  visual  impact 
could,  for  an  instant  or  two,  be  a  little  overwhelming. 

However,  if  you  concentrate  on  one  layer  at  a  time,  the 
diagrams  are  relatively  easy  to  read. 


READY? 


Let's  take  a  look  at  one  or  two  . . . 


1 1 


STEP-BY-STEP 
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VISUAL  TABLE  OF  CONTENTS 


A  visual  table  of  contents  precedes  the  DFDs  in  each 
processing  document. 

The  following  example  shows  a  table  of  contents  for 
Rights-of-Way.  It  gives  an  overview  of  the  levels 
according  to  hierarchy  involved  with  the  Rights-of-Way 
process. 


Getting  Close 
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VISUAL  TABLE  OF  CONTENTS 


You  will  note  that  each  process  is  identified  in  an 
ellipse. 


Whether  it's  a  table  of  contents  or  a  DFD,  an  ellipse 
always  represents  a  process. 

A  process,  then,  is  where  incoming  data  is  acted  on 
and  changed  somehow  to  produce  something  else- 

a  different  kind  of  data 
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VISUAL  TABLE  OF  CONTENTS 


You  will  also  notice  that  each  ellipse  contains  a 
decimal  number  and  a  process  name.  These 
identifiers,  much  like  a  table  of  contents,  correspond  to 
the  DFD,  the  narrative,  and  the  data  dictionary 
components. 

The  asterisk  (*)  appearing  in  some  ellipses  indicate  the 
primitive  level  of  the  process,  as  you  may  remember, 
that  portion  that  cannot  be  further  subdivided. 
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VISUAL  TABLE  OF  CONTENTS 


Using  our  example .... 

Rights  -of-Way  involves  three  basic  processes: 

Pre-Application  Consultation 

Application 

Process  Cases 


These  processes  are  then  subdivided  into  other 
processes  until  they  reach  the  point  (primitive  level) 
where  they  cannot  be  subdivided  further  (noted  by 
the  *). 
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VISUAL  TABLE  OF  CONTENTS 


Taking  one  segment  of  this  Table  of  Contents,  let's 
follow  this  thru  . . . 


Level  5 


Level  6 


Level  7 


(     Receiving 


Application  is  one  of  the 
Rights-of  Way  Processes.  The 
decimal  number  is  shorthand 
for  the  sixth  level;  the  number 
is  actually  1 .1 .2.2.7.2 


In  Level  7,  the  numbers 
»  are  also  shorthand  (1 .1 .2.2.7.2.1 
and  1.1.2.2.7.2.2).  In  this 
case,  the  seventh  level  is 
also  the  primitive  level  (*). 


Application  for  Rights-of-Way,  according  to  the 
example,  can  only  be  subdivided  into  2  other 
processes,  and  these  processes  cannot  be  subdivided 
further  (as  indicated  by  the  *). 
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DATA  FLOW  DIAGRAMS 


Now,  let's  see  how  the  DFD,  identified  in 
our  Visual  Table  of  Contents,  might 
look . . . 


APLN 


/C*Ec 


ACCOUWTIN 


E 


RESOURCE  EVALUATION 
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DATA  FLOW  DIAGRAMS 

With  the  subprocesses  (or  primitives)  looking 
something  like  this .... 


ROW      

DISP  OP 
ASSIGNMENTS 
1.1.2.2.7.3.5.2.1 


CR'ORCAAALMRS 


2 


ACCOUNTING  ,/L^^ 


ACCTG  ADVICE 


RESOURCE 

EVALUATION 

DECISION  FACTORS 

2.1 


ROW 
REVIEW  APLN 
FOR  COMPLETENESS 
_  1.1.2.2.7.3.2.2 


HUNTING   /I 


ROW         — 

CONDUCT 

COMPETTTIVE 

BID  PROCESSING 

1.1.2.2.7.3.1.2 


C3/ORCA.'AALMRS 


3 


ROW 

ESTABLISH 

5101  ACCOUNT 

1.2.2.7.3.2.1 


ROW 
REVIEW 
APLN  FOR 
COMPLETENESS  / 
FEE  I     1.1.2.2.7.3.2.2/7 


v 

^ACC 


INTINC    / 
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DATA  FLOW  DIAGRAMS 


It's  really  not  so  bad 


as  you 

will 

soon  see. 
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DATA  FLOW  DIAGRAMS 


For  starters,  let's  take  a  look  at  some  of  the  symbols. 


The  ellipse, 


The  arrov/s  going  in 


The  arrov/s  coming  out 


CF 


The  input  and  output 


The  brackets 


you're  already  familiar  with-it 
represents  a  process. 


are  input  (data  going  into  a 
process). 


are  output  (changed  data  coming 
out  of  a  process). 

APLN^ 

**^  arrows 

are  labelled  with  letters  or  words 
indicating  the  type  of  data.  (We 
can  now  see  the  clear  purpose  of 
having  a  data  dictionary.) 


internal  ENTiv>\     represent  processes  defined 

elsewhere  in  the  DFD  structure, 
yet  share  a  data  flow  with  the 
current  diagram  (an  off-the-page 
connector). 
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DATA  FLOW  DIAGRAMS 


he  rectangles  external  entity  identify  agencies, 

organizations,  and  systems 
outside  the  system  (process) 
being  analyzed.  These  serve  as 
original  sources  or  final 
destinations  (depending  on 
placement  on  the  diagram)  of 
data,  designated  as  such  in  the 
titles. 


A  diagonal  line  shown  on  the  top,  left  corner  of  a 
rectangle 


identifies  an  external  automated 
system. 


A  diagonal  line  on  the  lower  right,  coupled  with  a 


number 


indicates  the  system  appears 
more  than  once  on  the  diagram. 
The  number  itself  represents  the 
particular  occurrence  at  that  stage. 
(So  a  "2"  means  second 
occurrence  at  this  point  of  the 
process.) 
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DATA  FLOW  DIAGRAMS 


Occasionally,  two  parallel  horizontal  lines 


may  appear  on  a  diagram.  These 
represent  data  stores  (places 
where  data  resides  until  it  is 
needed--a  filing  cabinet  of  sorts). 
A  data  store  files  manual  or 
automated  information. 


For  example: 


LAND  USE  PLANS 
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DATA  FLOW  DIAGRAMS 


As  you  look  again  at  the  Application  DFD,  you  can  see 
that  Applicant/Holder  is  an  original  source. 

The  "1"  in  the  lower  right  diagonal  corner  indicates  that 
Applicant/Holder  is  used  again  somewhere  else. 


Sure  enough,  it  also  appears  as  a  final  destination 


E 


RESOURCE  EVALUATION 


APLN 
FEES 


J  ACCOUNTING^] 

a      I   APPLICANT// 
,X|      HOLDER  /; 


""     ROW  1 

DISPOF 
ASSIGNMENTS 
1.1.2.2.7.3.5.2.1 


CR/ORCA/AALMRS 


—        ROW 

REVIEW 

APLN  FOR 

COMPLETENESS 

1.1.2.2.7.3.2.2 


ROW 

CONDUCT 

COMPETITIVE  BIO 

PROCESSING 

1.1.2.2.7.3.1.2 


ROW 
ESTABLISH 
5101  ACCT 
_J.  1.2.2.7.3.2.1 
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DATA  FLOW  DIAGRAMS 


On  the  diagram  below,  Applicant/Holder^ ,  you  see  the 
Accounting  process  that  appears  not  only  here  (Level 
1)  but  also  on  the  subtasks  (Level  2).  (Brackets 
are  the  clue!) 


For  instance,  Accounting  appears  twice  on  this 
diagram  (indicated  by  the  lower  right  corner  number) 
and  four  times  in  the  subtask  diagram  (clue  was  the 
brackets). 


So,  Accounting  is  a  process  that 
over  and  over  in  the  Application 
piece  of  the  process. 


appears  over  and 
Process  --  a  critical 


-_2^J  j    ASSIGKM6HTS 

|_M.  2.2.7.3. 3. 2J_ 


now 
Cisc  op 

ASSIGKMEWTS 


E 


RESOURCE  EVALUATION 


Level    1 


DATA  DICTIONARY 

OK ...  but  what  kinds  of  data  are  coming  from  the 
Applicant/Holder  or  the  Accounting  process? 

After  it's  gone  through  the  Application  process,  how 
has  the  data  changed? 

Why  can't  the  information  be  in  regular  English  ? 
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DATA  DICTIONARY 


The  answer  to  the  last  of  these  questions  is  easy  - 
There  simply  isn't  enough  room.  The  DFD  builders 
want  the  diagram  to  be  as  uncluttered  as  possible. 
So  they  used  abbreviations  and  shorthand  terms  that 
meant  something  to  them. 

They  also  want  to  make  things  easy  for  the  reader. 

The  Data  Dictionary  makes  sure  everyone 
understands  the  diagram,  whether  they  worked  on  the 
process  or  not. 

It  identifies  the  data  for  the  reader  --  and  a  WHOLE 
LOT  MORE. 
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DATA  DICTIONARY 

So  looking  at  our  diagram  again,  let's  see  how  the  Data 
Dictionary  can  help  — 


APLN 
FEES 


E 


J  accounting] 

B      I   APPLICANT// 
>*1      HOLCER  /; 


now 

OISP  OP 
ASSIGNMENTS 
1.1.2.2.7.3.S.2.1 

■£2 


DECEIVING    J/ 

-*TCR/ORCA/AALMRS 


RESOURCE  EVALUATION 


—       ROW 

REVIEW 

APLN  FOR 

COMPLETENESS 

1.1.2.2.7.3.2.2 


ROW 

CONDUCT 

COMPETITIVE  BIO 

PROCESSING 

1.1.2.2.7.3.1.2 


ROW 

ESTABLISH 

S101  ACCT 

1.1.2.2.7.3.2.1 
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DATA  DICTIONARY 


A  quick  look  at  the  Data  Dictionary  shows  us  the 
following: 

DMA  DICTIONARY  AND  CROSS  REFERENCE  LIST 


Example  1 


Example  2 


Key 


Data  Name 

1  > 

Abbreviation 

2  Description 

3  Data  Type 
Ability  to  View 

4  > 

Ability  to  Update 

5  Definition 


Data  Name 

Abbreviation 

Description 


Data  Type 
Ability  to  View 
Ability  to  Update 

Definition 


Application 
Apln 


A  formal  request  for  •  right-of-way  which  includes  Forff) 
299  and  related  supporting  data. 


Record 

Internal  BLM  until  authorized 

Used  by  BLM  personnel 

{Form  299  ♦  ({topographic  maps   |   (Survey  Maps   | 
{transportation  system  maps)  *  {description  of  proposed 
project  ♦  {special  requirements  or  consideration  from  the 
applicant  +  {Proof  of  Citizenship  *  {Corporation  documents 
♦  (plan  of  development) 


Case  riles 


CF 

A  serialized  folder  that  contains  all  necessary 

Information  to  process  an  application  and  administer  the 
authorization.     The  serialization  may  be  the  State  office 
number  system  or,  1n  the  case  of  0»C  roads,  •  district 
number  system. 

Set 

All 

BLM  personnel  until  authorized,  public  Info  after 
authorization 

Application  ♦  {Maps  ♦  {Master  Title  Plats  ♦  {Land  Report  | 
08C  Resource  Analysis  ♦  ({Categorical  Exclusion  j 
Environmental  Assessment  |  Environmental  Statement]  * 
Appraisal  Report  (1f  required)  ♦  Accounting  Adv1ce(s)  * 
authorization  documents  ♦  {Compliance  Report  ♦ 
Authorization  Renewal  *   assignment  decision  4 
relinquishment  accepted  decision 


Identification  -  Abbreviation  and  what  it  represents. 

Data  uses  and  characteristics 

Data  type 

Security  considerations  for  retrieval/update 


1. 
2, 
3. 
4. 
5.   Definition 


32 


DATA  DICTIONARY 


Most  of  these  are  pretty  straight  forward. 

However,  you  may  have  some  questions  regarding  the 
notations  in  the  Definition  Section. 


This  may  help 
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Some  commonly  used  notations. 


& 


b 


Definition  $Form  299  4  C$topographic  maps   |   SSurvey  maps   | 

Stransportation  system  maps!  +  Idescrlption  of  proposed 
project  4  Ispecial  requirements  or  consideration  from  the 
applicant  +  SProof  of  Citizenship  +  $Corporation  documents 
♦  (plan  of  development)  Z~~ 


a:  %data  Primitive  component 

(elements  not  described 
elsewhere  in  the  Data 
Dictionary)-in  this 
example,  the  data  is  Form 
299. 

b.  [data  1  \  data  2]  Selection  of  components 

c.  data  1  +  data  2  Multiple  components 

d.  {data)  Optional  components 


DATA  DICTIONARY 

Some  other  commonly  used  notations. 

{data }  Repetitive  component 

1  {data}  10  Repetitive  component 

within  limits 

*  comment  *  Qualifying  Comment 

"data "  Literal/actual  data 


Note:  A  cross  reference  list  is  often  included  in  the 
data  dictionary  if  an  entry  has  initials  or  an 
abbreviation  associated  with  its  actual  name. 
This  list  of  abbreviations  and  full  data  dictionary 
names  may  be  used  to  quickly  find  a  data  flow  in 
the  dictionary  when  it  is  referenced  on  the  DFD 
only  by  abbreviated  forms. 
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You're  probably  beginning  to  see  just  how  intertwinec 
and  complex  the  components  of  a  process  really  are. 
You  may  not  have  realized  the  magnitude  before. 

You're  also  probably  beginning  to  appreciate  the 
necessary  thoroughness  of  DFDs.  They  actually 
"contain"  an  entire  process  in  one  manageable 
package. 

They  answer  all  your  questions,  without  creating  new 
ones. 
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INPUT-^PROCESS-*  OUTPUT  NARRATIVE 


But 


Does  anything  more  need  to  be  said  once  the  Primitive 
level  is  reached? 
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INPUT-^PROCESS-* OUTPUT  NARRATIVE 


Very  possibly  . . .  just  in  case  there  could  be  more 
questions. 


Some  may  want  or  need  to  know  more  -- 
others  may  not. 


...  but  adding  this  information  to  a  DFD  may  only 
clutter  the  diagram,  rather  than  help  the  user. 
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INPUT-^PROCESS-* OUTPUT  NARRATIVE 

For  those  who  want  or  need  more  information,  the 
INPUT-^PROCESS-^ OUTPUT  NARRATIVE 
picks  up  the  loose  ends it  further  defines  the  finite. 

Once  more  to  the  DFD  example — 


Visual  Table  of  Contents 


DFDs  for  Primitives 


Accou»mi»c  /] 
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INPUT-^PROCESS-*  OUTPUT  NARRATIVE 


And  on  to  the  companion  narrative- 


INPUT 


•PROCESS 


■OUTPUT  NARRATIVE 


Process  Name: 
Identifier: 


Application  Receiving 
1.1.2.2.7.2.1 


Parent  Process  Name:  Application 


Description: 


Receive  materials  and  determine  1f  materials  are  a  new 
application  requiring  serialization,  or  an  amended/renewal 
application,  or  Information  relating  to  an  existing  case. 


Policies/Procedures:  None. 


Constraints: 
Input 


Application  • 
Application  Fees 


None. 


Process 


Receive  Application  and  Application 
Fees  from  applicant/holder  and 
determine  proper  authority. 
Application  used  1n  this  process 
could'  include  the  application  form, 
further  project  descriptions,  proof 
of  licensing,  maps,  plats, 
signature  on  application,  proposed 
amendment,  assignment,  temporary 
use  permit,  bonding,  etc. 

Date  stamp  the  application. 

Determine  if  a  new  application  or 
related  to  an  extsting  one. 

If  a  new  application,  send  Applica- 
tion and  Application  Fees  to 
"Serialize." 


Output 


Application 
Application  Fees 
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INPUT-^PROCESS-*  OUTPUT  NARRATIVE 

As  you  can  see,  the  Input-Process-Output  Narrative 

describes  the  logical  order  of  execution  within  the 
Primitive  process.  It  further  defines, 

-  What  is  entered  into  a  process, 

-  What  happens  during  the  process, 

and 

-  What  leaves  the  process. 


Note:  These  narratives  accompany  the  DFD  according  to  the 

numerical  order  they  are  defined  in  the  DFDs  (not 
alphabetically). 
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WHEW! 


(Tuff  parts  over!) 


t 


Ready  for  just  a  little  more? 
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WRAP  UP 


You  did  say  yes,  didn't  you? 


NOW  THAT  WE  HAVE  IT, 
WHAT  DO  WE  DO  WITH  IT? 


We  use  it  as  a  tool . . . 

As  part  of  the  Structured  Analysis  Process,  Data  Flow 
Diagrams 

Clarify  Data  Flows 

Identify  and  define  data 

as  it  enters  and  leaves 

a  process 

Help  us  understand 
an  entire  process 

Motivate  us  for  change. 
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NOW  THAT  WE  HAVE  IT, 
WHAT  DO  WE  DO  WITH  IT? 


We  can  use  it 


For  ADP  Systems  Applications 

The  documentation  from 
Structured  Analysis  accurately 
describes  the  current  way 
business  is  done,  lending  itself 
to  an  easier  transition  for  future 
automation. 

For  Modeling  and  Prototyping 

Having  current  system 
documentation  allows 
managers  to  clearly  identify 
what  needs  to  be  automated 
which  leads  to  a  better 
determination  of  software 
specifications. 


NOW  THAT  WE  HAVE  IT, 
WHAT  DO  WE  DO  WITH  IT? 

To  Develop  Data  Standards 

Standardization  Bureauwide 
has  not  been  a  high  priority.  As 
we  move  to  the  future,  the  need 
becomes  more  critical.  DFDs, 
because  they  use  case-type 
documentation,  can  be  used  as 
a  basis  for  Bureau  standards. 

To  Develop  Functional  Standards 

Regardless  of  job  title,  functions 
vary  from  office  to  office.  Since 
Structured  Analysis 
documentation  is  portrayed 
strictly  on  a  functional  basis,  it 
can  serve  as  a  Bureau  standard 
for  processing  cases. 


As  a  Tracking  System 


Many  of  the  action  codes  of 
DFDs  can  readily  serve  as 
benchmarks  for  tracking 
activities  through  the  life  cycle 
of  a  process. 


47 


NOW  THAT  WE  HAVE  IT, 
WHAT  DO  WE  DO  WITH  IT? 


To  Analyze  Workloads 

By  reviewing  the  steps  in  a 
process,  managers  and 
analysts  can  determine  better 
ways  for  people  to  complete 
their  assigned  tasks  and  also 
eliminate  duplication. 

For  Budget,  Annual  Work  Plan  Considerations 

By  being  able  to  review  each  of 
the  steps  in  a  given  process, 
managers  can  figure 
processing  time  and,  therefore, 
have  a  more  consistent  and 
realistic  basis  for  budget  and 
annual  work  plan  concerns. 


For  Staff  Reviews 


The  documentation  can  be 
used  in  developing  checklists 
that  would  help  in  reviewing  or 
approving  work  done  by  others. 
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NOW  THAT  WE  HAVE  IT, 
WHAT  DO  WE  DO  WITH  IT? 


In  Personnel 

Personnel  Staffs  could  use  the 
documentation  to  better 
understand  the  activities 
performed  by  various  Bureau 
employees.  This  could  result  in 
more  accurate  job 
classifications  and  better  staff 
selections. 

To  Create  Handbooks 

The  Step-by-Step  Process  of 
Structured  Analysis  lends  itself 
to  the  Step-by-Step  format 
needed  for  users'  handbooks. 


To  Update  Manuals 


Current  manuals  are  in  some 
cases,  incomplete  or  outdated; 
Structured  Analysis 
documentation  can  fill  the 
holes. 
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ffliiiiTTiiwTirrwiwmmnTin 


NOW  THAT  WE  HAVE  IT, 
WHAT  DO  WE  DO  WITH  IT? 


As  Training  Tools 

DFDs  are  a  useful  source  for 
the  way  the  Bureau  conducts  its 
business.  As  a  reference, 
DFDs  show  what  training  has 
been  attained  and  what  more 
needs  to  be  learned. 


p@ 


SO  WHAT'S  IN  IT  FOR  ME? 

Through  DFDs  you  have  a  good  modeling  tool,  a  visual 
network  of  the  goings-on  in  your  organization  and  its 
relation  to  the  rest  of  the  world. 

Complete  processes  are  contained  (in  one  package). 

Interrelationships  are  clarified. 

Data  types  and  data  flows  are  identified  and  defined. 

Needs  and  Requirements  are  weeded  out  from  the 
wants . 

Future,  necessary  actions  come  into  focus. 
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SO  WHAT'S  IN  IT  FOR  ME? 

As  such,  the  Structured  Analysis  package  (DFDs  and 
all)  offer  you  the  following: 

-  A  foundation  for  writing  systems  design 
specifications 

-  A  clearer  understanding  of  what's 
happening  around  you 

-  A  straight  forward  incremental  approach 
toward  automation  (homework  done  and  well 
documented) 

-  A  chance  to  automate  with  little  or  no  risk 
since  all  requirements  are  spelled  out  in 
advance 

-  A  preview  of  future  skills  that  will  be  needed, 
important  when  hiring  or  training 

-  An  opportunity  to  change  the  character  of 
the  way  business  is  done,  perhaps  never 
explored  or  dreamed  of  before 
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SO  WHAT'S  IN  IT  FOR  ME? 
$  $  $ 

Accurate  and  complete  analysis  = 
Accurate  and  complete  requirements  = 
Adherence  to  requirements  = 
Almost  fool-proof  design  = 
Fewer  changes  after  installation  = 
Smoother  transition  (people  &  automation)  = 

$  $  $ 
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STILL  NEED  MORE  INFORMATION? 


5=^=~D* 


Maybe  these  will  help  . . . 

They  served  us  well  as  references  and  can  provide  the 
in-depth  information  you  may  require. 


Dickinson,  Brian.  1981.  Developing  Structured 
Systems.  Yourdon  Press,  New  York. 

Logical  Conclusions  Inc.  1988.  Applied  Structured 
Analysis.  Brisbane,  California. 

Rhinehart,  Melanie.  August  1987.  Now  That  We  Have 
It.  What  Can  We  Do  With  It . . .  Department  of  the 
Interior,  Bureau  of  Land  Management,  Denver. 
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